System and method for detecting sources of abnormal computer network message

ABSTRACT

The present invention relates generally to a system and method for the monitoring of email and other message traffic on a network. The intent of the monitoring to determine if message traffic is abnormal, thus indicating unwanted messages such as spam. A number of methods may be utilized by the invention to recognize unwanted messages, including the calculation of fanout, the number of messages sent by a unique host, unique email address or domain. Also included is fanin, the number of messages received from unique hosts, unique domains or unique email addresses. Further components consider the number of error messages received from a host, variations in bandwidth from a host, and variations in message content from a host.

PRIORITY

This application claims the benefit of priority to Canadian PatentApplication Serial No. 2,466,567, filed on May 7, 2004.

FIELD OF THE INVENTION

The present invention relates generally to a system and method fordetecting abnormal patterns of computer message traffic, the intentbeing to determine if a host should be ignored as it appears to besending bulk email, viruses, worms or the like.

BACKGROUND OF THE INVENTION

With the mass growth of the Internet there has occurred a rising floodof unwanted messages. Many of these messages are what are typicallyreferred to as “spam”. Spam is the electronic equivalent of junk mail.In addition to junk mail, other messages may include programs such asviruses or worms. One of the intents of a worm is to control a hostcomputer for the purpose of sending more spam. Spam consumes a largeamount of network resources as well as wasted time for the users havingto deal with it.

There have been many solutions developed to deal with spam and unwantedmessages. The most common being the use of filtration software.Filtration software examines the content of a message and determines ifthe message is wanted or not. Typically filtration software maintains adatabase of sites known for sending unwanted messages as well asdatabases of keywords that help to identify an unwanted message. Such ascheme is costly in the use of computer time, as it must scan everymessage for content and check with a database. Further, it is simple toavoid filtration software by changing the address of the sender andmodifying the words of the message. Finally, filtration software mayexclude wanted messages based upon what is falsely considered a validkeyword or address match.

An advancement in filtration software is to use Bayesian or heuristicfilters to statistically identify unwanted messages based on thefrequencies of patterns in the message. These types of filters are weakwhen dealing with shorter messages, as they do not have enough data tomake an intelligent decision.

Another alternative is to create lists of IP addresses that are known tobe used by senders of unwanted messages. These are known as “blacklists”and aid in blocking messages from the listed addresses. The problem withthis approach is that the blacklisted senders move addresses readily andthe person who is reassigned the previous address may still be on thelist, thus being incorrectly identified as a spammer.

Thus, there is a need for a means of detecting unwanted messages in acost effective and efficient manner. The present invention addressesthis need.

SUMMARY OF THE INVENTION

The present invention is directed to a method for detecting sources ofabnormal message traffic on a network, said method comprising the stepsof:

-   a) utilizing an abnormality detection engine to detect said abnormal    message traffic; and-   b) reporting on said abnormal message traffic.

The present invention is also directed to a method of wherein saidabnormality detection engine consists of one or more of componentsselected from the set of: a fanout detector, a fanin detector, an errorresponse detector; a bandwidth variation detector; or a message contentdetector.

The present invention is also directed to a system for detecting sourcesof abnormal traffic in a network, said system comprising an abnormalitydetection engine, said abnormality detection engine accepting messagesto and from said network and providing a report as output, saidabnormality detection engine comprising one or more abnormalitydetectors, selected from the set of: a fanout detector, a fanindetector, an error response detector, a bandwidth variation detector; ora variation in message content detector.

The present invention is further directed to a computer readable medium,for detecting sources of abnormal message traffic on a network, saidmedium comprising instructions for:

-   a) utilizing an abnormality detection engine to detect said abnormal    message traffic; and-   b) reporting on said abnormal message traffic.

The computer readable medium, wherein said abnormality detection engineconsists of instructions for one or more of a fanout detector, a fanindetector, an error response detector, a bandwidth variation detector; ora variation in message content detector.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the present invention, and to show moreclearly how it may be carried into effect, reference will now be made,by way of example, to the accompanying drawings which aid inunderstanding an embodiment of the present invention and in which:

FIG. 1 is a block diagram illustrating how the present invention may beutilized;

FIG. 2 is a block diagram of the functional components of an AbnormalityDetection Engine;

FIG. 3 is a flowchart of the logical structure of the fanout detector;

FIG. 4 is a flowchart of the logical structure of the error responsedetector;

FIG. 5 is a flowchart of the logical structure of the bandwidthvariation detector; and

FIG. 6 is a flowchart of the logical structure of the variation inmessage content detector.

DETAILED DESCRIPTION OF THE INVENTION

The present invention is referred to as an “Abnormality DetectionEngine”, ADE. It is not the intent of the inventors to restrict the useof the invention simply to the detection of spam, but rather to allow itto be utilized to detect any form of unwanted messages.

Referring now to FIG. 1, a block diagram illustrating how the presentinvention may be utilized is shown generally as system 10. System 10comprises an Internet Service Provider (ISP) network 12 and an externalnetwork 14. Messages, such as email are exchanged by hosts 16, betweennetworks 12 and 14. Each host 16 is capable of sending and receivingmessages. In the case of email, each host 16 will utilize a Mail UserAgent (MUA, not shown) such as Microsoft Outlook to send and receivemessages. All messages sent between networks 12 and 14 will pass throughADE 18. ADE 18 monitors messages and passes them to or receives themfrom a router 20. In the case of email messages a Mail Transfer Agent(MTA) 22 is utilized to forward or receive messages. In system 10, MTA22 is shown as being part of network 12 but it may also reside withinnetwork 14.

System 10 is meant merely to indicate how the present invention,residing within ADE 18 may be deployed. As one skilled in the art willrecognize, any number of configurations may be utilized to make use ofthe present invention. By way of example, ADE 18 may reside outside ISPnetwork 12.

Referring now to FIG. 2 a block diagram of the functional components ofan Abnormality Detection Engine is shown. ADE 18 takes as input a datastream 30 and provides as output a stream of reporting data 32. Stream30 comprises all messages to be monitored by ADE 18. Stream 32 may takeany number of forms such as being stored in a database, being displayedto a system administrator graphically, or formatted in reports. Theintent of stream 32 is to provide those interested with information onabnormal messages.

ADE 18 comprises five main components, each of which serves as detectorsof anomalies in network traffic. One or of more components may beenabled and configured for a specific implementation. Fanout detector 34examines data stream 30 to determine if an abnormal amount of messagesare being sent (Fanout) by a host to multiple addresses. By the termaddress we mean to include: an IP address, a domain name, an emailaddress and any other means for identifying a unique source or recipientof a message. Fanout can be an indication that a host is sending toomany unwanted messages. Fanin detector 36 examines data stream 30 todetermine if an abnormal amount of traffic is being received from asingle address. Error response detector 38 looks for an abnormal amountof error messages. Messages incorrectly addressed to an MUA are anindication of unwanted messages. Bandwidth variation detector 40determines if a sender of messages is providing a steady rate ofmessages. A steady rate of messages is not typical of human use of anetwork and indicates a source of unwanted messages. Variation inmessage content detector 42 examines messages to determine if messagescoming from a single source are largely the same.

FIG. 3 is a flowchart of the logical structure of the fanout detector,shown as feature 34 of FIG. 2. Fanout is a measure of distinctaddresses. A typical MUA may utilize a few MTA's, so an indication of anincrease in addresses may help in determining if a host is beingutilized to deliver unwanted messages.

To describe the fanout detector in more detail, we begin at step 34 a.At step 34 a information on the source and destination of the currentmessage are extracted. Typically these would be IP addresses, but theycould also be domain names or email addresses. By way of example, SimpleMail Transfer Protocol (SMTP) response messages may be monitored throughthe use of a packet capture library to monitor Transmission ControlProtocol/Internet Protocol (TCP/IP) port 25 for email. At step 34 b atest is made to determine if the source and destination can bedetermined, if so, the fanout counter for the source and destinationpair is incremented at step 34 c. In the case of SMTP messages, thefanout counter would count the number of messages sent to each uniqueaddress. At step 34 d a test is made to determine if it is time togenerate a report on the information collected, if not processing movesto step 34 e where processing for the current message ends. If it isdetermined at step 34 d that a report should be prepared, processingmoves to step 34 f. At step 34 f a test is made to determine if thethreshold for fanout has been met. Experimentation indicates that athreshold value of 20 for each unique address is an indication ofsending spam. If the threshold has not been met, processing moves tostep 34 h. If the threshold has been met, processing moves to step 34 g.At step 34 g reporting data is prepared to indicate that the destinationIP address is a source of abnormal traffic. This report corresponds toreporting data 32 of FIG. 2. The user may wish to reset fanout countersin a deterministic manner, for example on regular schedule, or on memoryused. At step 34 h it is determined if the fanout counters should bereset. If not, processing returns to step 34 e. If the fanout countersneed to be reset, this is done at step 34 i.

Fanin detector 36 functions in a similar manner as fanout detector 36.The distinction being that fanin detector 36 examines messages todetermine if an abnormal number of messages have been received from aunique address as opposed to messages being sent. The logic for fanindetector 36 is identical to that shown in the flowchart of FIG. 3, savethat the counters track fanin rather than fanout.

Referring now to FIG. 4 a flowchart of the logical structure of theerror response detector, feature 38 of FIG. 2 is shown. Error responsedetector 38 examines messages to determine if a message is a “reject”message. By way of example, In the case of email an MTA may reject amessage and make it known to the sender. Similarly in the case ofHypertext Transfer Protocol (HTTP) a Uniform Resource Locator (URL) maynot be found, resulting in a reject message. A well behaved MUA is notlikely to receive more than a few reject messages. A large number orreject messages is an indicator of abnormal messages.

Beginning at step 38 a the response to a message from an MTA is read. Atstep 38 b, if the message is not an error response it is ignored at step38 c. If the message indicates an error response, processing moves tostep 38 d were a counter for the MTA is incremented. At step 38 e a testis made to determine if a report, shown as feature 32 of FIG. 2, shouldbe generated. If no report is required, processing ends at step 38 c. Ifa report is required, processing moves to step 38 f where a test is madeto determine if a threshold has been met to require the generation of areport. Experimentation has shown that for SMTP messages an error countof ten messages from a unique address is an indication of spam. If thethreshold has been met, processing moves to step 38 g and a report isgenerated. If not, processing moves to step 38 i. At step 38 i a test ismade to determine if the error counters should be initialized. The usermay wish to initialize the error counters in a deterministic manner, forexample on a regular schedule, or on memory used. If so, processingmoves to step 38 h to initialize the error counters, it not processingfor the message ends at step 38 c.

Referring now to FIG. 5 a flowchart of the logical structure of thebandwidth variation detector, feature 40 of FIG. 2 is shown. Beginningat step 40 a, a message is read to determine the destination address ofthe message. At step 40 b a counter corresponding to the destinationaddress is updated. At step 40 c a test is made to determine if it istime to generate a report on bandwidth variation. If the result isnegative, processing moves to step 40 d and the message is ignored. Ifthe result is positive a calculation is made on bandwidth variation. Theintent here is to detect anomalies in message traffic. Typicallymessages from an MUA would be in bursts, consistent traffic may beindicative of a spam host. Any number of schemes may be used todetermine if an abnormality in bandwidth variation exists. The use of amoving average has been found to work well. A test is then made at step40 f to determine if the desired threshold for bandwith variation hasbeen met. If so, a report, shown as feature 32 of FIG. 2, is generatedat step 40 g, if not, processing moves to step 40 h. At step 40 h a testis made to determine if the bandwidth counters should be initialized.Counter values may take up more memory than desired or a user may wishto have them reset on a regular basis. If counters are to be initializedprocessing moves to step 40 i, otherwise to step 40 d.

Referring now to FIG. 6 a flowchart of the logical structure of thevariation in message content detector, feature 42 of FIG. 2 is shown.Beginning at step 42 a, a message is read to determine the content ofthe message. For unwanted messages such as spam, the message contentwill scarcely vary. A number of algorithms may be used to detectvariation in content, such as hashing the content of the message or avariety of Lempel-Ziv, Huffman encoding or the like. It is not theintent of the inventors to restrict the variation in message contentdetector to any one algorithm. At step 42 b a test is made to determineif the message is similar to others sent from the same address, if sothe counter corresponding to the address of the source of the message isupdated at step 42 c. At step 42 d a test is made to determine if it istime to generate a report on variation in message content. If the resultis negative, processing moves to step 42 e and the message is ignored.If the result is positive, a test is conducted at step 42 f to determineif the desired threshold for message variation has been met. If so, areport is generated at step 42 g, if not processing moves directly tostep 42 h. At step 42 h a test is made to determine if the variationcounters should be initialized. Counter values may take up more memorythan desired, and from time to time it may be desired to reset them. Ifcounters are to be initialized processing moves to step 42 i, otherwiseto step 42 e.

Another feature of the present invention, not shown, is to utilize a“white list” within ADE 18. A white list would include information ontrusted sources of messages. A message coming from a source on the whitelist would not be examined by ADE 18.

In this disclosure, the inventors intend the term “counter” to refer toa count of the number of messages for a given address tracked by anabnormality detector, regardless of the abnormality detector in use. Ifthe counter exceeds the threshold for an abnormality detector, a reportis generated. For example, if a standard deviation were to be used todetect abnormal messages, the counter would be incremented for thosemessages that lie on the tails of the distribution.

Although the present invention has been described as being a softwarebased invention, it is the intent of the inventors to include computerreadable forms of the invention. Computer readable forms meaning anystored format that may be read by a computing device.

Although the invention has been described with reference to certainspecific embodiments, various modifications thereof will be apparent tothose skilled in the art without departing from the spirit and scope ofthe invention as outlined in the claims appended hereto.

We claim:
 1. A method for detecting a source or destination of abnormalmessage traffic on a network, said method comprising: tracking messagesbetween a plurality of sources and a plurality of destinations, whereintracking messages comprises: determining the source and destination of amessage; generating a source and destination pair counter for eachsource and destination pair; incrementing the source and destinationpair counter based on at least some of the messages and an amount ofmessages between said source and said destination; determining abandwidth variation of a rate of messages to a destination, whereindetermining the bandwidth variation comprises: generating a bandwidthcounter for each destination; updating the bandwidth counter based onthe rate of messages to a destination; and determining if apredetermined amount of time has passed; and comparing values in thesource and destination pair counter to a predetermined source anddestination pair threshold and comparing values in the bandwidth counterto a predetermined steady rate of messages after the predeterminedamount of time has passed to determine if there is abnormal messagetraffic related to a source or destination based on both comparisons. 2.The method of claim 1 wherein said traffic is email.
 3. The method ofclaim 1 wherein said traffic comprises HyperText Transfer Protocolmessages.
 4. The method of claim 1, wherein the at least some of themessages between said source and said destination comprise messageshaving similar content based on message content detection.
 5. The methodof claim 1, further comprising: generating a report if the source anddestination pair counter or the bandwidth counter surpass thepredetermined thresholds; and initializing either the source anddestination pair counter or the bandwidth counter after the report hasbeen generated.
 6. The method of claim 5 further comprising: trackingerror messages between the plurality of sources and the plurality ofdestinations, wherein tracking error messages comprises: determining ifan error message is a reject message; generating an error messagecounter for each source or destinations generating the reject message;and incrementing the error message counter based on the timing of theerror messages.
 7. A non-transitory computer readable medium, saidmedium comprising instructions, which when executed on a processor,cause the processor to perform the method of claim 1.